Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/875

Internet Message Format | 1994-08-27 | 5.9 KB

Subject: Re: Gem List (fwd)
Date: Tue, 19 Jul 1994 15:46:37 -0400 (EDT)
From: Chris Herborth <[e-mail]>
In-Reply-To: <[e-mail]> from "[e-mail]" at Jul 19, 94 12:00:08 pm
Message-Id:  <[e-mail]>
Precedence: bulk

What you wrote:
> Wrong. Our library is much *smaller* than Gem++, yet has many more features.
> The resulting executables that do the *same thing* as the equivalent Gem++
> program are generally several times *smaller*, not to mention *faster*.
>
> Go figure.

Go figure indeed.  C++ programs are larger than C programs because the
_linkers_ being used were designed for C code.  Instead of being intelligent
and linking in only the used members of a class (which is sort of what
they do for C if your library is designed properly), it links in the whole
class, which can be quite large.

C++ programs will remain large until OO linkers are developed.  People
on _every_ platform complain about C++ programs being larger than C
programs, and some use this as a "why C is better than C++" argument,
which is silly, since it has nothing to do with either language, really.

How did you decide your GUIs were faster than GEM++'s GUIs, BTW?  In what
respect?  Does it somehow manage to draw a window faster?  Do your scrollers
scroll faster?  And what's the point if a programmer can use library A
more effectively than library B?

> WinLIB PRO was designed after intensive study of over *20* GUI libraries.
> It incorporates the best ideas of all of them (we steal from the best, and
> forget the rest :-) WinLIB PRO is extremely powerful, yet extremely
> easy to use. WinLIB PRO does most of the work for you, with an extremely
> straightforward, simple API.
>
> WinLIB PRO gives you the most amount of bang for the least amount of
> effort (and code wise, WinLIB PRO is very, very efficient. Very very small
> executables and very fast execution.)

I'll bet it won't make a GEM NetHack smaller than about 750k or so...  (Not
a fair test, since plain NetHack compiles to *at*least* 700-800k; I think
Warwick had to leave out several features in the GEM NetHack on
atari.archive... it's binary is over 800k if I remember correctly.)

And when are you releasing the source code?

> Sozobon produces good object code? *laughs* I think your standing with most
> of the people in this conference has dropped about 20 points from that
> comment alone. Sozobon code is mediocre to fair, but far from 'good'.

Which is exactly what I'd call the Pure C optimiser...  GNU C's code may
be large, but it's VERY good.  Personally, I have a hard drive, so I could
care less if my binaries are a bit larger.

> I think that if people in this conference spoke more from EXPERIENCE and less
> from OPINION, we would be much more productive.

In my EXPERIENCE and OPINION, assembly-language debugging is a cruel
joke and a massive waste of time.  Some people swear by it though.  I
prefer a souce-level debugger that speaks C or C++ to me...

> Very very few people I know are using MTOS. Most are disgusted with it like
> I am. I know of *nobody* (except maybe you) who actually LIKES it. Even on a
> Falcon030 it makes life miserable. On a TT it's barely tolerable.

On a Falcon, using a half-way reasonable graphics mode makes life
miserable; forget multitasking.

> If you're talking about C++, you're right; it DRAGS EVERYTHING
> in your library along with it whether it's used or not...

No it doesn't; the linker is stupid and drags everything in every _class_
you use into your program.  This is wastefull and silly, but C++ is still
a major win over C, IMHO.

> Consider the amount of people who use C++ over C on the atari, then re-think
> the question about who will use the library.  I think you can answer that.

Oh, good!  Now we can go over why almost no-one (only the brave, the elite
few!) uses C++ on the Atari again... whee.  It's a pointless point unless
you plan to *sell* your library; then you need to decide if you should
support the dozen or so people using Lattice, or the dozen or so people
using Pure/Turbo C, or the dozen or so people using gcc.  Ok, maybe more
than a dozen in each, but still, the numbers are not stunning in either
of them.  If you support Pure/Turbo C, you get to compete with all those
free GEM libs from Germany...

Something that just occured to me, folks...  WHY are we discussing various
GEM libraries on the gem-list at this point?  I thought we were trying
to hammer out some standards here...  I'm amazed at how argumentative this
mailing list is (but then, I guess *all* Atari users need to blow off
steam somehow these days).

> (I could go into a discussion on memory fragmentation from alloc'ing and
>  free'ing memory for dynamically growing and shrinking a listbox, but I
>  digress...)

Reasonable C support libraries should have malloc() and free() in them
that keep track of larger chunks (usually 64k from what I've seen); that
way, if you're going to malloc() a bunch of small things, and free() a
few, then malloc() a few more, you're not fragmenting memory...  I'm
presuming that you're playing devil's advocacte a little here, since nobody
in their right mind would use the Malloc() GEMDOS call.

> I never claimed otherwise. I just pointed out that to change from a normal
> slider to an active slider in Gem++ required a code change and recompilation
> whereas in WinLIB PRO it simply requires a change to the slider's extended
> object type in the resource editor.

The change for GEM++ would likely be changing one line of code; not a big
deal if you're working on the application anyway.  The slider/active slide
decision should be part of your design, not something you throw in for
fun later.

Uh-oh, now we'll get into the consistant-user-interface argument again... :)

--
----------========================_   /\ ============================----------
Chris Herborth                    \`o.0'       [e-mail]
Information Products Developer    =(___)=
AT&T Global Information Solutions    U